1. Technical Field
The present disclosure relates generally to clients and servers in a data processing network, and more particularly to a data processing network using the Representational State Transfer (REST) architecture style. The disclosure more specifically relates to managing and using sessions in a data processing network providing RESTful web services.
2. Introduction
Representational State Transfer (REST) is an acronym coined in Roy Fielding's doctoral dissertation to characterize the architecture style of the World Wide Web. RESTful web services refer to distributed processes that provide services (functions) to the client software following the REST principles. See chapter 5 of Fielding, R., Architectural Styles and the Design of Network-based Software Architectures, Ph.D. Dissertation, University of California, Irvine, Calif., 2000. The World Wide Web (WWW), commonly known as the Web, is a system of interlinked hypertext documents accessed via the Internet. REST includes an abstraction of the architectural elements within the WWW, and a set of constraints applied to these architectural elements. The REST architectural elements include data elements, connectors, and components.
The REST data elements include resources, Uniform Resource Identifiers, representations, representation metadata, resource metadata, and control data. A resource is the intended conceptual target of a hypertext reference. Thus, a resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. A Uniform Resource Identifier (URI) is a generic term for all types of names and addresses that refer to objects on the WWW. A URL (Uniform Resource Locator) is one kind of URI. A URL provides a means for locating the resource by describing its primary access mechanism (e.g., its network “location”). REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes. For example, an HTML document or a JPEG image is a representation.
The REST connectors provide a generic interface for accessing and manipulating the value set of a resource, regardless of how the membership function is defined or the type of software that is handling the request. REST connectors include clients, servers, caches, resolvers, and tunnels. A dynamic name service (DNS) is an example of a resolver. A Secure Socket Layer (SSL) is an example of a tunnel.
The REST components include origin servers, gateways, proxies, and user agents. A user agent uses a client connector to initiate a request and becomes the ultimate recipient of the response. The most common example is a Web browser, which provides access to information services and renders service responses according to the application needs. An origin server uses a server connector to govern the namespace for a requested resource. It is the definitive source for representations of its resources and must be the ultimate recipient of any request that intends to modify the value of its resources. Intermediary components act as both a client and a server in order to forward, with possible translation, requests and responses. A proxy component is an intermediary selected by a client to provide interface encapsulation of other services, data translation, performance enhancement, or security protection. A gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcement.
The first REST constraint is separation of the user interface concerns from the data storage concerns, in a client-server relationship. Separation of the user interface concerns from the data storage concerns improves the portability of the user interface across multiple platforms and improves scalability by simplifying the server components.
The second REST constraint is that the client-server communication must be stateless. In particular, each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Application state is therefore kept entirely on the client. This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
The third REST constraint is a cache constraint that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
The fourth REST constraint is a uniform interface between the client, server, and intermediate components. The software engineering principle of generality is applied to the component interface, so that the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability.
The fifth REST constraint is a layered system constraint. The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting. By restricting knowledge of the system to a single layer, a bound is placed on the overall system complexity and substrate independence is promoted. Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary. Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.
REST also provides an option of client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional feature within REST.
In general, a session is an exchange of data between an association of participants. In a distributed system, a client typically invokes a service to establish the association of the participants, and the service provides a mechanism to maintain client state across subsequent client invocations of the service during the session. For example, there are many applications of the Internet that require the creation and management of such a session. It is particularly useful in communication protocols and services because many of them, such as Session Initiation Protocol (SIP), Jingle, Parlay X and Computer Supported Telecommunications Applications (CSTA), require that a client establishes a session with the services or peers first, before data is exchanged between clients. To move communication systems into a web centric architecture, communication web services often have to integrate with various session-based protocols to connect them into the web infrastructure. Because these session-based protocols have different session formats, it is important for the integrated web services to present a uniform session interface to hide the variations and complexities from the web service clients. Without such a uniform session service, the integrated web services would be more complex and more difficult to interoperate.
Despite its importance, however, there is no standard way to establish sessions for web services. Over the years, various techniques, including the Hypertext Transfer Protocol (HTTP) cookie, URI rewrite, hidden form field, etc., have been developed to address the session issue on the Web. The lack of a common session mechanism has created confusions among web service development and has limited interoperability among web services.
The HTTP cookie is defined in Kristol et al., HTTP State Management Mechanism, Request for Comments 2965, October 2000, Network Working Group. The HTTP cookie is a mechanism for managing HTTP states. A HTTP cookie is a piece of data structure that associates an arbitrary name-value pair with a set of HTTP server data, including domain, path and ports. A cookie can be discarded when the user agent exits or expires after a certain specified duration. The cookie is set by the HTTP response when the user interacts with a web server and the set cookie is sent by the web browser back to the server when the target URL matches the domain, path and ports in the cookie. A user can also delete the remembered cookies from the web browser to prevent them from being sent.
The cookie mechanism has several problems, as pointed out by a Wikipedia article on the HTTP cookie. From the REST point of view, a HTTP cookie is not an addressable resource that can be controlled by the web service clients. As the result, there is no standard way for a client to decide or access the content of a cookie, delete a cookie from the server at will or change its expiry duration. Because of this lack of control, cookies also break the statelessness principle of REST when a client revisits URLs prior to cookie. Further details of this problem can be found at page 252 of Leonard Richardson & Sam Ruby, “RESTful Web Services,” 2007, O'Reilly Media, Inc., Sebastopol, Calif.